The present invention relates to Telnet proxies and, more particularly, to Telnet proxies that buffer option negotiation commands until after Telnet sessions are established between clients and remote servers.
Telnet is a well-known computer network protocol used to establish a connection over a network between a real or emulated terminal and a remote computer (also called a “remote server” or simply a “host”). Such a Telnet session enables a user to log in to the remote host and to engage in an interactive session with the host. A Telnet session is typically carried over a TCP/IP connection.
A Telnet session is established between a client and a server. Between the client and the server, the Telnet session simulates a Network Virtual Terminal (NVT). Data from the client, such as characters typed on a keyboard, is treated as though it was entered on the NVT, and the data is delivered to the server. Similarly, data sent by the server is treated as though it is displayed on the NVT. If a user uses Telnet to log in to a remote host, the user typically executes a terminal emulator program (the client), such as on a personal computer. The terminal emulator accepts input from a real keyboard and treats the input as though it was entered on the NVT. The terminal emulator displays characters received by the NVT on the user's real display device.
To accommodate the wide variety of hardware and software, such as keyboards and displays, that the user and the remote host can use, the Telnet protocol defines how characters sent between the client and the server are treated. These characters include 95 printable characters (such as letters, digits and punctuation marks) and 33 control characters, such as BS (backspace), CR (carriage return) and HT (horizontal tab). Most characters, such as a-z, A-Z, 0-9, punctuation marks, BS, HT (horizontal tab), FF (form feed), etc., have their normal meanings.
In addition, the Telnet protocol allows the client and the server to negotiate various options. For example, the client and the server can negotiate whether characters entered by the user are echoed locally by the terminal emulator or remotely by the server. Each party (the client and the server) can request the other party to perform or to not perform a specified option. In addition, each party can, on its own (i.e., without a request from the other party), declare to the other party that the declaring party will or will not perform a specified option.
Sometimes these option negotiations are constrained by hardware or software limitations in the client or the server. Thus, one party might refuse to perform a requested option, because it is incapable of performing the function. In other cases, one party can arbitrarily refuse to perform a requested option.
An option negotiation is conducted by sending a series of WILL, WON'T, DO and/or DON'T Telnet commands between the parties. The WILL command is used by either party to indicate that the party is willing to begin performing a specified option. For example, a first party sends a “WILL Echo” command to indicate that the party is able and willing to echo characters locally. The other party sends a “DO Echo” or “DON'T Echo” command to request that the first party begin locally echoing characters or not, respectively. The first party then responds with a “WILL Echo” or “WON'T Echo” as a positive or negative acknowledgment, respectively.
A Telnet proxy is an entity that resides in a network connection between a client and a server. The proxy presents an interface to the client in which the proxy appears to be a server. Similarly, the proxy presents an interface to the server in which the proxy appears to be a client. Some conventional Telnet proxies authenticate users, such as by requiring the users to enter valid user names and passwords, before establishing a Telnet session between the user's client and a requested remote host. When a Telnet connection is established between the client and the host, the Telnet proxy passes data sent by either party to the other party.
Some conventional Telnet proxies negotiate options with clients before establishing Telnet sessions with remote hosts, then attempt to negotiate the same options with the remote hosts. However, if the remote hosts reject the negotiation attempts, the proxies must then renegotiate the options with the clients. These renegotiations can be inconvenient and time consuming.
Some conventional Telnet proxies do not permit option negotiations to occur until after a Telnet session is established with a remote host, because the capabilities of the remote host are not known until after the Telnet session is established. However, this deferral of options negotiation delays the productive portion of the user's session with the remote host.